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Abstract 

It is a little known fact that, despite Apple's claims, any applica- 
tions downloaded from the App Store to a standard iPhone can access 
a significant quantity of personal data. 

This paper explains what data are at risk and how to get them pro- 
grammatically without the user's knowledge. These data include the 
phone number, email accounts settings (except passwords), keyboard 
cache entries, Safari searches and the most recent GPS location. 

This paper shows how malicious applications could pass the manda- 
tory App Store review unnoticed and harvest data through officially 
sanctioned Apple APIs. Some attack scenarios and recommendations 
are also presented. 
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1 Introduction 



1.1 Background facts 

This subsection presents some quick facts and figures for people unfamiliar 
with the iPhone. 

1.1.1 Market share 

Apple introduced the iPhone on June 29, 2007. iPhone worldwide market 
share of smartphone sales to end users was 17% in Q3 2009 1 . In late 2009, 
34 millions iPhones had beed sold 2 . 

1.1.2 App Store 

Developers distribute iPhone applications through Apple's App Store, 
which had more than 100,000 applications available'^ in late 2009. As of 
January 5, 2010 three billion applications have been downloaded 1 in 70 
countries worldwide. 

1.1.3 Jailbreak 

In its standard configuration, the iPhone only runs software cryptographi- 
cally signed by Apple. However, iPhone hackers have found ways to circum- 
vent this limitation by creating a modified version of the iPhone OS that 
will run any code. Installing such a firmware is called "jailbreaking". Most 
"jailbroken" devices feature an SSH server and enable the root login at the 
same time. According to Intego° about 6-8% of all iPhones are "jailbroken" . 

1.2 Motivation 

1.2.1 Press reports 

The second half of 2009 has been a huge commercial success for Apple, 
but at the same time numerous reports have surfaced about privacy issues 
with the iPhone. 

Customers of ID Mobile's MogoRoad iPhone application are com- 
plaining that they're getting sales calls from the company, a pro- 
cess which turns out to be technically a piece of cake. 

The Register, 30th September 2009 

http : //www. theregister . co.uk/2009/09/30/iphone_security/ 

x http : //www . gartner . com/ it /page . jsp?id=1224645 
http : //www . apple . com/pr/library/ 
3 http : //www . apple . com/pr/library/2009/ll/04appstore .html 
4 http : //www . apple . com/pr /library/20 10/0 l/05appst ore .html 
5 http : //blog . intego . com/2009/11/11/ 
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A maker of some of the most popular games for the iPhone has 
been surreptitiously collecting users' cell numbers without their 
permission, according to a federal lawsuit filed Wednesday. 

The Register, 6th November 2009 

http : //www. theregister . co .uk/2009/ 11/06/ iphone_games_storm8_ 
lawsuit// 

iPhone owners in Australia awoke this weekend to find their de- 
vices targeted by self-replicating attacks that display an image of 
1980s heart throb Rick Astley that's not easily removed. 

The Register, 8th November 2009 

http : //www. theregister . co .uk/2009/ 11/08/ iphone_worm_rickrolls 
users/ 

In a world where lost or stolen laptops and phones scream at us 
from newspaper headlines and data breaches invite multi-million 
dollar government fines and lawsuits, do we want a smartphone 
whose insecurity is well documented? In our judgment, no. 

Sharon D. Nelson and John W. Simek, Sensei Enterprises, 2009 

Mark Bregman, Symantec's executive vice president and CTO, 
highlighted mobile security as a critical area to monitor in the 
new year, in which "more attackers will devote time to create 
malware to exploit these devices". In a separate report, Symantec 
noted that Apple's products, including its popular iPhone, will 
face increased attacks from cybercriminals. 

ZDNet Asia, 9th December 2009 

http : //www . zdnetasia . com/news/sof tware/0 , 39044164 , 62059902 , 
00. htm 

Should people care? Should they be scared? Can users trust iPhone 
applications because they are reviewed by Apple? What about corporate 
environments? The aim of the work presented in this paper is to get facts 
and a clear view of iPhone privacy issues, in order to help consumers and 
professionals taking sensible and well-informed decisions. 

1.2.2 Outline of the paper 

This paper starts by defining privacy and presenting an overview of past 
iPhone privacy issues. 
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Next, it specifically considers the unmodified devices and examines what 
sensitive data may be compromised by an application downloaded from the 
App Store. Because seeing is believing, the source code of a proof-of-concept 
malicious application was made available publicly. 

This paper goes on to explain how a malicious application could be crafted 
to fool Apple's mandatory reviews in order to be accepted on the App Store. 
Finally, it discusses several attack scenarios, tries to suggest improvements 
and delivers basic recommendations. 

This paper doesn't try to compare other mobile platforms such as An- 
droid, Windows Mobile or BlackBerry. It also doesn't discuss data harvest- 
ing on desktop computers. 

2 Privacy, spy ware and law 

2.1 Privacy and spyware 

According to the Merriam- Webster's dictionary, privacy is the quality or 
state of being apart from (. . . ) observation. In the context of spyware 
applications, we can consider privacy more narrowly as personal data confi- 
dentiality. 

By spyware, I mean an application that gathers personal data without the 
user's knowledge and consent. So what is personal data? At the end of the 
day, the definition that matters is the legal one. Of course, it depends on the 
country one lives in. Because the author of this paper lives in Switzerland, let 
us have a quick look at Swiss law, which is quite strict regarding protection 
of privacy. 

Note that this law is only applicable if the spyware author is either resident 
in Switzerland, or if the government can successfully negotiate extradition 
to Switzerland. In the European Union, the extradition is allowed by the 
Convention on Cybercrime 6 . 

2.2 Swiss law 

2.2.1 Personal data 

The Swiss Federal Constitution states that everyone has the right to be 
protected against the misuse of their personal data (Art. 13 al. 2). Personal 

6 http : / /conventions . coe . int/Treaty/EN/Treaties/html/185 .htm 
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data are then denned in a specific law called the Federal Act on Data Pro- 
tection (FIDP), which defines personal data as all information relating to 
an identified or identifiable person (FIDP Art. 3 lit. a). 

2.2.2 Personality profile 

The same law defines a collection of personal data as a "personality pro- 
file". It permits an assessment of the essential characteristics of the per- 
sonality of a natural person (FIDP Art. 3 lit. d). Personality profiles are 
especially protected and strictly regulated (eg. FIDP Art. 11 lit. a al. 3). 

2.2.3 Spy ware authors 

Now, where are the legal responsibilities? Spyware authors may be jailed 
for up to three years and have to pay big fines for "obtaining personal data 
without authorization" (Criminal Code Art. 179 novies). Also, applicable 
civil laws can be used to impose hefty fines (Breaches of privacy FIDP Art. 
12.2, Breach of obligations to provide information or to cooperate FIDP Art. 
34). This is scarcely applied, though. 

2.2.4 End users 

End users are protected from over reaching End User License Agreements 
(EULAs). Arbitrary provisions that have been "snuck into" EULAs are void 
(Civil Code Art. 2 al. 1). Thus, the EULA cannot simply state that you 
agree to send your personal data to bad guys if you do not. There must be 
a real mutual agreement, ruling out the use of potentially misleading terms 
(Civil Code). 

2.2.5 Technical staff 

In case of damages, civil liability may apply to technical staff if the plaintiff 
can prove that an organization failed to protect confidential data properly 
(FIDP-0 Art. 8, 9, 10, 11, 12). Under this law, liability could extend all 
the way to Apple itself. For more detail, see this document [2] by the Swiss 
Federal Data Protection and Information Commissioner. 

3 History of iPhone privacy concerns 

This section presents the main privacy issues that have been encountered 
on the iPhone. Figure 1 summarizes them on a timeline. 
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Figure 1 : Timeline of the main past privacy issues 



3.1 Root exploits 

Here are two well known root exploits on the iPhone. The vulnerabilities 
were quickly patched by Apple, but could have been exploited to steal private 
data. 

3.1.1 libtiff 

July 2007. The first exploit was due to multiple buffer overflows' discov- 
ered in libtiff by Tavis Ormandy. The vulnerable libtiff version was used 
by the Apple's ImagelO framework. The simple opening of a maliciously 
crafted TIFF image could lead to arbitrary code execution, as demonstrated 8 
by Rik Farrow. Apple patched 9 this vulnerability in iPhone OS 1.1.2. 

3.1.2 SMS fuzzing 

July 2009. This exploit was presented at Black Hat USA 2009 by Charlie 
Miller and Collin Mulliner. The researchers presented an iPhone vulnera- 
bility 10 that could allow a hacker to seize control of the phone through ma- 
liciously crafted SMS messages. The vulnerability was patched 11 in iPhone 
OS 3.0.1. 

7 CVE-2006-3459, CVE-2006-3461, CVE-2006-3462, CVE-2006-3465 

8 http : / /www . fast company . com/mult imedia/2007/ll/hacking- the- iphone .html 

9 http : //support . apple . com/kb/HT2170 

10 http : / /securityevaluators . com/content/news/index . jsp?topic=iphone_sms_ 
2009 

lx http : / /support . apple . com/kb/HT3754 
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3.2 Personal data harvesting 
3.2.1 Aurora Feint 



In July 2008, the popular iPhone game Aurora Feint was the first appli- 
cation to be pulled from the App Store due to privacy concerns. The game 
would upload all the contacts stored in the iPhone to the developer's server, 
allegedly to discover if any of the user's friends also play that game. 

3.2.2 MogoRoad 

In September 2009, the Swiss road traffic information application MogoRoad 
was pulled from App Store after users complained they got sales calls from 
the company. MogoRoad is back on App Store after Mogo's explanations 12 . 

3.2.3 Storm8 complaint 

In November 2009, a federal lawsuit was filed in California against iPhone 
applications editor Storm8, whose games had already been downloaded more 
than 20 million times. The games were harvesting the user's phone number 13 
without encryption. Since then, Storm8 games have stopped collecting the 
users' phone numbers. 

3.2.4 Pinch Media 

Pinch Media is a free analytics framework used by many iPhone devel- 
opers. It collects anonymous usage data from mobile phone applications and 
could be compared to Google Analytics. 

In July 2009, some bloggers started to raise serious concerns 15 about Pinch 
Media, claiming that iPhone users were being tracked by some applications 
without their knowledge and without the possibility of opting out. Accord- 
ing 16 to Pinch Media, the collected data are: 

- a unique hardware identifier 

- the model of your phone and operating system 

- the application's name and version 

- the result of a check to see if the device has been jailbroken 

- the result of a check to see if the application has been stolen 

- the length of time the application was run 

12 http : //www.mogo . ch/presse/ID_M0BILE_C0MMUNICATE_M0G0R0AD_EN .pdf 
13 http : / /www . sf gate . com/cgi-bin/blogs/ybenjamin/detail?entry_id=46236 
14 http : / /www . pinchmedia . com/ 

lj http : / /i- phone -home . blogspot . com/2009/07/pinchmedia-anatomy-of - spyware-vendor . 
html 

16 http : / /www .pinchmedia. com/blog/pinch- media-user-privacy- and- spyware/ 
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- if the user explicitly agrees to share it, the user's location 

- if the application uses Facebook Connect, the gender & age of the user 

3.3 Worms on jailbroken devices 

November 2009 saw an important wave of worm attacks targeting jail- 
broken iP hones. All of them exploit the fact that very few users bother to 
change the default root password (alpine) after jailbreaking their iPhone 
and installing an SSH server. 

3.3.1 Ikee 

Ikee is the first known iPhone worm. It changes the iPhone's wallpa- 
per and displays a photograph of 1980s singer Rick Astley with the words 
Ikee is never gonna give you up. It was written by a 21-year old australian 
programmer, who was subsequently hired by the Australian iPhone devel- 
opment company mogeneration. 

3.3.2 Dutch 5 € ransom 

This worm locked the screen with the following message: Your iPhone's 
been hacked because it's really insecure! Please visit doiop.com/iHacked and 
secure your iPhone right now!, until the user had paid a 5 € ransom on a 
PayPal account. The Dutch hacker has now taken down his PayPal, returned 
the money he earned and published free instructions on how to remove the 
backdoor. 

3.3.3 iPhone / Privacy.A 

This worm steals personal data but, unlike the previous worms, does not 
reveal its presence. 

3.3.4 Ikee.B / Duh 

This worm is highly pernicious. It connects to a Lithuanian master, like 
a traditional botnet node. It changes the root password into "ohshit", 
steals private data and attempts to infect other hosts. The worm also tries 
to exploit ING Direct bank's two- factor authentication by using SMS. This 
worm was analyzed by SRI International [5]. 

3.4 iPhone forensics 

Physical access to any device means that pretty much everything can be 
compromised, with the notable exception of passwords, which are stored 
encrypted in the phones Keychain. 
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Jonathan Zdziarski [3] showed that both the passcode and the disk en- 
cryption could be bypassed and the full iPhone disk image could be retrieved 
unencrypted by an investigator with the proper tools. This led an unnamed 
mid-sized US law firm (50 plus lawyers) to completely ban the iPhone . 

An interesting white paper [6] on iPhone forensics was also released in 
March 2009 by viaForensics. 

3.5 Security solutions editors 

As a result of the late 2009 worms, Apple got a lot of bad press, much of 
which was unjustified. Some people criticize Apple for having an insecure 
configuration, whereas in fact worms only target jailbroken devices that have 
an SSH server and root access with the default password. It has also been 
suggested that jailbroken iPhone are more secure than stock devices because 
users can theoretically install firewalls. 

Neither firewalls nor antivirus products are available for stock iPhones, 
from either Apple or third parties, so, not surprisingly, security software 
editors are among the most vocal critics. 

Chester Wisniewski from Sophos writes on his blog that iPhones are not 
ready for the business environment 18 because they can be jailbroken. This is 
somewhat unfair. Would anybody claim that Linux is not ready for business 
because you can exploit a weak default root password on an SSH server? 

Thus, F-Secure 19 and Intego 20 argue that Apple should modify the iPhone 
OS design and allow background running applications with a broader access 
to the OS, which would have the significant effect of allowing vendors to 
offer security solutions to iPhone users. 

4 Writing spyware for the iPhone 

4.1 Methodology 

Now imagine that we would like to write a spyware for the iPhone. It 
would look like a breakout game and actually play breakout but, at the 
same time, silently harvest personal data and send them to a remote server. 

17 http : / /ridethelightning . senseient . com/2009/12/my-entry .html 

18 http : / /www . sophos . com/blogs/ chetw/g/2009/ll/21/malicious-iphone-worm-loose/ 

19 http : //www . itpro . co .uk/6 18 154/security-f irms- cannot -protect -the- iphone-f rom- threats 

20 http : / /www . theregister . co . uk/2009/ 11/25/ iphone_anti_malware/ 
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In order to reach the App Store, the spyware can't normally use private 
APIs, because this is forbidden by Apple and checked during the mandatory 
review process. It must also run on a non-jailbroken iPhone, namely on the 
original iPhone OS version 3.1.2, which is the latest version available at the 
time of writing. 

Let's look for entry points to steal personal data within these constraints. 
We consider neither hardware attacks — see [3] on this matter — nor root 
exploits. Also, we don't target the information voluntarily submitted by 
users, such as Facebook or Twitter profiles, although a real- life spyware 
would certainly be interested in these data. It would be really easy to 
harvest Twitter or Facebook details, by offering to upload high scores to 
social networks. 

4.2 Entry points 

4.2.1 Cell Number 

The first and easiest item of personal data to collect is the user's phone 
number. This number is entered in iTunes when the phone is first connected. 
The good news is that you can change it anytime in iPhone Settings. The 
number is stored in the file . GlobalPref rences . plist. Listing 1 shows hot 
to retrieve the number programmatically. 

Listing 1: Retrieve the cell phone number 

NSDictionary *d = [NSUserDef aults standardUserDef aults] ; 
NSString *phone = [d valueForKey:@''SBFormattedPhoneNumber M ] ; 



Novice iPhone programmers sometimes think that they need the cell 
number, when in fact they just need some kind of device-specific identi- 
fier. In this case, they should use the Objective-C method -[UIDevice 
unique Identifier] . Note that this unique identifier can also raise privacy 
concerns, as discussed in section 7.1.6. 

4.2.2 Address Book 

Another way to collect personal data is through the Address Book API. It 
turns out that the full Address Book is readable without the user's knowledge 
or consent. It contains names, users' phone numbers and email addresses, 
but also a "notes field" , in which many Mac users store sensitive data such as 
door codes or bank accounts. These notes are synchronized with the user's 
computer and may be harvested on the iPhone. Moreover, a spyware can 
edit the Address Book, that is add, change or delete any record, without 
the user's knowledge or consent. 
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This surprising state of affairs appears to reflect a deliberate decision by 
Apple. This API is very similar to the one on the Mac, but it lacks the "Me" 
record, as if Apple had sought to prevent the iPhone owner identification. 

Spammers can easily retrieve all the email addresses, and more sinister 
scenarios are all too readily imaginable. For example, if a rogue application 
alters the email addresses, there is a great potential for harm, because the 
Mail application displays the contact's full name only, and a confidential 
email could be sent to the wrong address (see attack scenarios section 6). 

The Address Book issue is one of the most serious for corporate environ- 
ments. 

4.2.3 File system 

Next, we consider the data that can be read on the iPhone filesystem. 
A sandboxing mechanism limits access to other application's data. Third- 
party applications are installed in /private/var/mobile/Applications/ 
and are prevented from seeing each other or accessing specific locations, 
such as the Music Library for instance. 

The sandboxing mechanism is implemented at the kernel level and de- 
scribed by a set of rules shown in the file SandboxTemplate . sb (appendix 
A). See man sandbox on Mac OS X for more details. 

About the sandboxing mechanism, Apple writes: 

Applications on the device are "sandboxed" so they cannot access 
data stored by other applications. 

In addition, system files, resources, and the kernel are shielded 
from the user's application space. 

Apple, iPhone in Business: Security Overview [1] 

It turns out that, despite sandboxing, numerous system and application 
preference files are in fact readable (see listing 2) by downloaded applica- 
tions, and some of them contain personal data. This concerns primarily 
preference files in plist format, but is not limited to them. The file system 
can be browsed and the content of these files viewed using the open-source 
file system browser FSWalker 21 . 

21 http : //f swalker . googlecode . com/ 
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Indeed, as suggested by the comments found in the file in the appendix 
A, the sandbox rules are far too loose. This appears to be a case of security 
being sacrificed in the rush to get a product to market. 

Note that our spyware doesn't even need undocumented APIs to read 
these files. Also, the user is never asked nor informed of the application 
poking the file system. He cannot prevent it. 

Listing 2: Printing the paths readable on the file system 

- (void)printReadablePaths { 

NSFileManager *fm = [NSFileManager def aultManager] ; 
NSDirectoryEnumerator *dirEnumerator = [fm enumeratorAtPath:®"/"] ; 
NSString *path = nil; 

while (path = [dirEnumerator nextObject] ) { 
if([fm isReadableFileAtPath:path] ) { 
NSLog«8" — '/,<&", path) ; 

} 

} 

} 



4.3 Introducing SpyPhone 

At this point, we know where to find personal data, including the phone 
number, the Address Book contents and several other pieces of data readable 
on the file system. A spyware would want to gather the potentially valuable 
information from all these sources. SpyPhone 22 is an open-source 23 proof 
of concept "that does just that" . Figure 2 shows the files actually read by 
SpyPhone. Let's have an overview of the data the rogue application can 
collect. You may want to look at the source code for details. 

The spyware can access the 20 most recent Safari searches (figure 3) and 
YouTube history (figure 4). It can access the email account parameters 
(figure 6), such as the full name of the user, the email address, as well as 
the host and login. The password is kept safe in the Keychain. The email 
content itself is not accessible, thanks to correct sandbox rules. 

The spyware can access data about the phone (figure 5) itself, starting 
with the phone number, as discussed in section 4.2.1. The spyware can also 
read the iPhone UUID (through a documented API), the ICCID (SIM card 
serial number) and the IMSI (International Mobile Subscriber Identity), 
making it possible to track users even when they change their device. IMSI 
reveals the country and the mobile operator. 

22 http : / /github . com/nst/spyphone/ 

23 You still need an iPhone developer certificate to install it on a non jailbroken iPhone. 
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/var /mobile/Library/Keyboard/ 

/var /mobile/Library/Preferences/ com. apple . account settings .plist 
/var/mobile/Library/Pref erences/com. apple . commcenter .plist 
/var/mobile/Library/Pref erences/com. apple .mobilephone . settings .plist 
/var/mobile/Library/Pref erences/com. apple .mobilephone .plist 
/var/mobile/Library/Pref erences/ com. apple . mobilesaf ari .plist 
/var/mobile/Library/Pref erences/ com. apple .preferences . datetime .plist 
/var/mobile/Library/Pref erences/ com. apple . weather .plist 
/var/mobile/Library/Pref erences/com. apple . youtube .plist 
/var/mobile/Library/Pref erences/com. apple . Maps .plist 
/var/mobile/Media/DCIM/ 



Figure 2: Paths actually read by SpyPhone 

Figure 7 shows the email addresses stored in the Address Book database. 
It is also possible to display any other field, as discussed in 4.2.2. 

The keyboard cache contains all the words ever typed on the keyboard, 
except the ones entered in password fields. This is supposed to help au- 
tocompletion but this mechanism effectively acts as a key-logger, storing 
potentially private and confidential names and numbers. Figure 9 shows the 
structure of a keyboard cache file containing the dictionary. There is one 
cache file per language. The keyboard cache can be reset in iPhone Settings. 

Any application has read and write access to the DCIM directory that 
contains the photos stored in the iPhone. By default, these photos are tagged 
with the GPS coordinate. By listing (figure 10) the date and location of each 
one, SpyPhone can thus keep detailed track of a user's physical movements. 
These data can then be mapped (figure 11). Note that SpyPhone can also 
send the photo itself by reading it on the file system, where a program 
would normally be able to access only one image at a time through the 
UllmagePickerController class, chosen by the user, and without EXIF and 
GPS data. 

The first time an application needs to access the GPS location, it prompts 
the user. But a spyware could also gain a pretty accurate estimate of the 
user's location without enabling the GPS. It could simply read the previous 
position in the Maps application preferences (figure 12). It could also know 
which areas you are in simply by reading the weather cities. A marketer 
rarely needs a more precise location. 

Another file keeps track of every time you join a Wifi network. Based on 
these logs, it is possible to gain insights into the user recents' whereabouts. 
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Figure 3: Safari Searches History 
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Figure 5: Phone and Hardware 



Figure 6: The email accounts 
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Figure 7: AddressBook emails 
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Figure 8: The keyboard cache 
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Figure 9: A keyboard cache file. There is one per language. 



For instance, our spyware knows that, on January 19th, I was as at school 
at 19:28 and then at Cafe du Simplon at 20:18 (figure 13). 



4.4 Valuable data 

Safari recent searches (figure 3), YouTube history (figure 4) and your 
keyboard cache (figure 8) give clues about your current interests. These 
interests are linked with your name and your email addresses (figure 6), 
your phone number (figure 5) and your area (figure 12). Harvested from 
large numbers of users, such data have a huge value in the underground 
market of personal data, and it must be assumed that trojans are in fact 
exploiting this on the App Store. 
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Figure 13: Win connection log 
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Also, the approximate location (figure 12), recent calls (figure 5, geo- 
tagged photos (figure 10) and Win connection logs are potentially valuable 
for forensics purposes. 

5 Getting published on the App Store 

To be published on Apple's App Store, an application must be submitted 
by a developer enrolled in the (paid) "iPhone Developer Program" 24 . Apple 
only gets the executable file, not the source code. Next, the application 
goes through an approval process which mainly looks for user interface in- 
consistencies but also undocumented function calls and yes, malware. The 
challenge for a malware author is to go unnoticed through this process. 
When approved, the binary is properly signed by Apple and can be run on 
any device. For paid applications, Apple keeps 30% of the revenues. 

5.1 App Store and malware 

5.1.1 The purpose of reviews 

Apple's tight control over the App Store is resented by many 25 devel- 
opers 26 . Moreover, it normally takes about one week, which may be pro- 
hibitively slow for security updates. This delay can be shortened by asking 
for an expedite review, though. The reasons for rejection are often 2 ' per- 
ceived to be arbitrary and unreasonable. 

Apple's senior vice president Phil Schiller explained 28 that Apple needs to 
ensure that everything works as expected by consumers. Apple also intends 
to reject applications which are in a legal gray zone such a casino gambling 
or collecting personal data, which seems only reasonable. Nonetheless, with 
some 10,000 binaries submitted each week, invariably, some malware are 
going to sneak through. 

5.1.2 iPhone software development kit agreement 

Every iPhone developer is bound by the terms of Apple's iPhone SDK 
Agreement. Unfortunately, this agreement forbids iPhone developers from 
commenting on its terms and conditions: 

24 http : / /developer . apple . com/ iphone/program/ 

2j http : / /www. joehewitt . com/post /innocent-until-pr oven-guilty/ 
2e http : / /www . paulgraham . com/apple . html 

27 http : / /www . tuaw . com/2008/08/07/thoughts- on- the- iphone- app- store- review-process/ 
28 http : / /www .businessweek . com/print /technology/ content /no v2009/tc20091120_ 
354597.htm 
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5.4 You may not issue any press releases or make any other 
public statements regarding this Agreement, its terms and condi- 
tions, or the relationship of the parties without Apple 's express 
prior written approval, which may be withheld at Apple's discre- 
tion. 

As a consequence, I won't be commenting further here, except to note that 
it states that developers should comply with local laws and regulations, and 
should not harvest users' personal information. Spy ware submitted to the 
App Store are rejected on this basis. 

The content of the agreement has been divulged on Wikileak and Wired 29 . 

5.2 Hiding the beast 

5.2.1 The review process 

The exact App Store analysis reviewing process is unknown and the fol- 
lowing considerations are only guesswork based on actual App Store rejec- 
tions 30 and knowledge of Apple development tools. Nonetheless, it is safe 
to assume that Apple probably mixes static and dynamic analysis. 

Note that even if Apple had access to the source code, it probably could 
not afford a full security code review, and malware authors would just hide 
malicious behavior a bit better, as demonstrated each year in the Under- 
handed C Contest^ 1 . 

5.2.2 Static analysis 

The static analysis probably consist of dumping the strings in the binary 
file — say with the "strings" command — and checking them against a 
black list of forbidden class and method names as well as file paths. This 
process can easily be circumvented with simple yet effective obfuscation 
techniques, as shown in listing 3. 

Listing 3: Simple yet effective string obfuscation technique 

- (NSString *) stringMimisl : (NSString *)s { 

NSMutableString *s2 = [NSMutableString string] ; 
for(int i = 0; i < [s length] ; i++) { 
unichar c = [s characterAtlndex: i] ; 
[s2 appendFormat:@'7.C" , c-1] ; 

y 

return s2; 

29 http : //wired. com/images_blogs/gadget lab/files/ iphone- sdk- agreement .pdf 
30 http : / /appreview . tumblr . com/ 
31 http : / /underhanded . xcott . com/ 
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- (void) viewDidAppear : (BODL) animated { 
NSString *pathPlusl = 

@"0wbs0npcjmf OMjcsbszOQsf gf sf odf tOdpn/bqqmf /bddpvoutf uuj oht/qmjtu" ; 
// @"/var /mobile/Library /Preferences/ com. apple . account settings . plist " 
NSString *path = [self stringMinusl :pathPlusl] ; 

NSDictionary *d = [NSDictionary dictionaryWithContentsOf File : path] ; 
// ... 



5.2.3 Dynamic analysis 

The dynamic analysis probably consists in running the "I/O Activity" 
instrument in Apple's Instruments application and checking the paths of 
opened files against a black list of forbidden paths. Such a process is easily 
circumvented by delaying the malicious behavior to a later date, triggered 
by a flag to be set remotely or activated only in a specific geographic area. 

5.2.4 Private APIs 

Apple is known to look for calls to private APIs (undocumented APIs) 
and reject applications on that basis. This is why our SpyPhone application 
does not use any of them and indeed it does not really need to. 

However, a real spyware author probably wouldn't mind and would take 
advantage of Objective-C's ability to lookup classes and selectors by name at 
runtime. This way, he could define them remotely or obfuscate their usage. 

According to my research, using private APIs doesn't help much in har- 
vesting personal data. The most interesting piece of data is the IMEI number 
(listing 4), which uniquely identifies a specific mobile phone being used on 
a mobile network. 

Private APIs can be browsed with iPhone Objective-C Runtime Browser 32 . 
Listing 4: Using a private API to dynamically retrieve the IMEI number 

NSString *path = @"/System/Library/PrivateFrameworks/Message . framework" ; 
BOOL bundleLoaded = [ [NSBundle bundleWithPath:path] load]; 

Class NetworkController = NSClassFromString(@"NetworkController") ; 
NSString *IMEI = [[NetworkController sharedlnstance] IMEI] ; 



http : / /runtimebrowser . googlecode . com 
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5.3 Apple's kill switch 

Rumor has it that Apple can remotely deactivate iPhone applications. 
In July 2008, iPhone forensics expert Jonathan Zdziarski [3] discovered a 
URL (see figure 14) with a Core Location 33 black list. This black list can 
prevent an application from using the Core Location functionalities, as an 
anonymous contact at Apple confirmed 34 to noted Mac blogger John Gruber. 
However, Apple has apparently never used the black list nor acknowledged 
its existence publicly. 

How would our SpyPhone be affected by this kill switch? The short answer 
is: not at all! SpyPhone uses various informations to estimate the location, 
including the last GPS lookup from Maps, and does not use Core Location 
directly. 



# curl https://iphone-services.apple.com/clbl/unauthorizedApps 
{ 

"Date Generated" = "2010-01-20 17:23:37 Etc/GMT"; 
"BlackListedApps" = {}; 

} 



Figure 14: Core Location black list 



6 Attack scenarios 

Here are some attack scenarios, outlining the potential consequences of 
a "privacy attack" and illustrating ways in which iPhone security is not as 
good as it should be. 

6.1 The spammer 

A breakout game is made available for free on Apple's App Store. While 
you are playing breakout, it reads your email address, your recent Safari 
searches, your weather cities and the words contained in your keyboard 
cache. 

When you submit your high score to the application's server, stolen in- 
formation is sent at the same time in an encrypted form. The application 
also sends all the email addresses in your address book. 

33 Core Location is the iPhone's framework for locating the device's position through 
GPS or A-GPS. 

34 http : //daringf ireball . net/2008/08/core_location_blacklist 
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Now the spammer knows your interests from Safari searches and the key- 
board cache. It also knows your location thanks to weather cities. This 
information can then be used to send you targeted commercial offers, or it 
can be sold on to other parties. 

6.2 The blackmailer 

A collaborative application on Hollywood gossip is made available for free 
on the App Store. While giving clues about spotting stars, it surreptitiously 
goes through your address book and edits the email addresses. 

Knowing that film industry people are likely to download this applica- 
tion, the emails they send are diverted to a clandestine server, providing 
potentially compromising private information to a prospective blackmailer. 

The approach can be tailored to produce the same scenario in the indus- 
trial, political or financial world. 

6.3 The luxury products thief 

An application for Rolls Royce owners or art collectors could report the 
name, the area, the phone and the geotagged photos of wealthy people. This 
is enough informations to rob them, especially if it can be determined that 
the targeted individuals are currently away from home. 

6.4 The jealous husband 

Unlike the previous scenarios, this one needs a physical access to the 
device. 

A detective, an evil competitor or even a jealous husband may be inter- 
ested in stealing the personal data in an iPhone to which they have physical 
access. All that is needed to do so is a Mac, a 99 USD Apple developer 
license and a USB cable. It takes just five minutes to install SpyPhonc, 
steal the personal data with the "email report" function, erase the evidence 
by deleting the sent mail and delete SpyPhone itself. 

Nothing has been jailbroken, no expensive device wiper was involved, and 
a horde of valuable personal data has been stolen. The iPhone owner need 
never suspect anything, and the jealous spouse or business competitor has 
full liberty to study Wifi connection logs, photo library dates and geotags 
for evidence that, say, the partner was not at the office at a given time. 
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Figure 15: French Prime Minister Figure 16: Frangois Fillon showing his 

and French former Justice Min- iPhone on TV (iphon.fr). 
ister using an iPhone (business- 
week. com). 

6.5 VIPs 

It is easy to imagine how an attack could be targeted against a particular 
individual. For example, French Prime Minister Frangois Fillon (figures 15 
and 16) is very proud of his iPhone and takes it everywhere. Fillon is a 
native of the French region called la Sarthe, where he also has his political 
roots. There is a significant likelihood that he would download an iPhone 
application designed to provide local breaking political news. It does not 
take much imagination to see the potential for damage in such a scenario. 



7 Recommendations 
7.1 For Apple 

7.1.1 Don't rely on security through obscurity 

First of all, Apple should stop claiming [1] that an application cannot ac- 
cess data from other applications (see 4.2.3). This is clearly wrong, mislead- 
ing and dangerous. Secondly, Apple should decide if the observed behavior, 
present since day one, is a flaw or not. If it is not, then Apple should docu- 
ment it properly. But if it is, Apple may have to review its secure software 
development lifecycle (S-SDLC) process. Given Apple's interest in corporate 
environments and the level of competition, this is a matter of credibility. 

7.1.2 Win connection log and keyboard cache 

There is no reason why the wifi connection logs should be readable. The 
same applies to the keyboard cache, which should be an OS service asso- 
ciated with text fields. It should not be possible to retrieve their whole 
contents. 
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7.1.3 Firewall and analytics frameworks 

The iPhone clearly lacks an optional outbound firewall similar to Lit- 
tleSnitch 35 on the Mac. Such a service would allow people to opt-out from 
the various analytics frameworks. An alternative would be to implement 
a single switch that gives consumers some kind of universal or per frame- 
work tracking opt-out option. This is what PrivaCy 36 does in the jailbroken 
world. 

At the end of the day, the fact that so many developers use analytics 
frameworks may be a hint to Apple to give more usage information to de- 
velopers, and provide users a setting to opt-out. 

7.1.4 Address Book 

Users should be required to grant access to the Address Book (see 4.2.2) 
individually for each application, as is currently the case for the Core Loca- 
tion framework. A breakout game has no business accessing your contacts. 
Moreover, a separate request should be prompted before editing the Address 
Book. I may want to authorize a quick dialer to retrieve my contacts, but I 
certainly don't want it to change them without my knowledge and consent. 

The risk, naturally, is that the security rules and settings become over- 
whelming, as in Windows Vista or in the Java security model, which shifts 
the burden entirely to the consumer. The resulting annoyance and irritation 
leads many users to simply allow everything. 

7.1.5 Towards Apple approved security policies? 

To stay in line with the current model where most of the iPhone security 
depends on Apple and not the user, Apple could ask application develop- 
ers to establish a security policy for their applications. For instance, the 
Info.plist file could contain a Policy dictionary allowing HTTP access to 
a specific URL and Core Location usage, but preventing Address Book or 
file system access. These policies would then be assessed by Apple's review- 
ers (figure 17). This might be one way to mitigate risk without the user 
having to manage complex security policies. 

This approach is actually a very simple version of a self-defined sandbox- 
ing principle called model-carrying [7] . The generation of models could be 
automated, and it would be possible for the App Store pages to describe it 

35 http : / /www . obdev. at/products/littlesnitch/ 

36 http : / /cydia. saurik. com/package/ com. saurik. privacy 
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Figure 17: Developers could submit a security policy with their application. 
Apple would ensure that authorizations are tight enough, and risks would 
be mitigated without users being overwhelmed with security pop-ups. 



in simple terms to potential customers. This is where a closed system could 
actually be a benefit for users who just want their phone to work. 

7.1.6 Device unique identifier 

The device unique identifier is currently available through the official 
SDK's API. While it is not personal data since it cannot identify a physical 
person, it may be used to aggregate data collected from various applications 
and analytics frameworks. 

As a general rule, an application should not be able to know which other 
applications you have run. Users merely accept cross-site cookies on the 
web, they probably would not accept their computer's unique identifier to 
be transmitted to Google Analytics. 

A possible solution for Apple would be to add something like an app- 
device identifier or ADID. This value would be unique for a given device 
and the requesting application. The current device unique identifier could 
be kept, but the user should be asked to allow or deny its usage, as with 
Core Location. 

7.2 For consumers 

Consumers should be aware that iPhone security is far from perfect and 
that a piece of software downloaded from the App Store may still be harmful. 
As a basic precaution, users should regularly clean the browser's recent 
searches and the keyboard cache in Settings. They should also change or 
delete the declared phone number, also in Settings. 
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7.3 For professionals 

Professional users should avoid running untrusted applications, especially 
if they are required by law to protect data confidentiality. This includes 
groups such as bankers, attorneys, medical staff, law enforcement officers 
and so on. Also, legal departments should be aware that confidential data 
may already have leaked. 

An answer to this potential spyware issue may be Apple's program for 
iPhone enterprise deployment 3 ' , which lets administrators create configura- 
tion profiles enforcing restrictions such as disabling Safari or disabling the 
App Store. 

8 Conclusion 

Overall, Apple has addressed iPhone security in a sensible manner to pro- 
tect most of the data. The file system permissions rely both on Unix permis- 
sions and on the sandboxing system. Passwords are kept safe, encrypted in 
the Keychain. Application databases are not readable by other applications. 
Overall security improves with each new iPhone version, but some basic se- 
curity principles are still not correctly implemented, in particular the least 
privilege principle, the deny by default principle and also a recognition that 
it is dangerous for Apple to deny the existence of vulnerabilities. 

Unix permissions, sandboxing system rule sets and App Store reviews are 
all very well in theory but their actual implementation is flawed. Numerous 
files are still readable directly by an application downloaded from App Store 
(section 4.3), mainly preference files, but also the photo library including 
geotags, the keyboard cache and the Wifi joined networks history. Combined 
with full access to the Address Book and the phone number, these data are 
too tempting for cyber criminals not to be exploited by spyware, especially 
in a store dominated by free and "one-buck" applications. 

To be useful, a trojan would still need to be distributed on the App Store. 
The fact that our SpyPhone application does not use private APIs would 
greatly help it pass unnoticed through the App Store review. The huge 
quantity of submissions, and the fact that reviewers only have the binary 
code to review, make it easy to hide the malicious behavior, as shown in 
section 5.2. Consequently, it must be assumed that spyware are currently 
on the App Store. 

37 http : / /www . apple . com/ iphone/business/ integration/ 



26 



While the fact that personal data are accessible will not be a complete 
surprise for experienced iPhone developers, the scale of such access probably 
will. Some may consider that this is unavoidable and therefore normal. Such 
an attitude, however, amounts to denial, and exposes users to major privacy 
incidents including massive identity theft and other targeted attacks (section 
6). 

It is a matter of concern that, two years and a half after iPhone's introduc- 
tion, and despite its huge commercial success, Apple has not fully addressed 
several basic filesystem privacy issues and, even worse, continues to dissemi- 
nate misleading information in its public documentation on iPhone security 
(section 4.2.3). The danger is therefore that the problem, far from being a 
bug that you can fix, may be closer to something like a design flaw. 

I hope that this paper will give the general public and professionals a 
clearer view of the real risks, and some clues on how to assess and mitigate 
these risks, so that they can decide themselves how they should use their 
iPhones properly in their private lives or corporate environments. 

I also want to make it clear that you should have no illusion: in the fast- 
paced environment of smartphone operating systems, every platform has its 
own flaws. To Apple's credit, it has at least a first line of defense against 
harmful applications, in the form of App Store reviews. At a time when 
malware are appearing on Android Marketplace 38 , this defense should be 
retained and improved. 
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A Sandboxing rules 

Here is the file /usr/share/sandbox/SandboxTemplate . sb, which doc- 
uments the rules enforced at the kernel level. Comments are part of the 
original file. 

(version 1) 
(deny default) 

; Sandbox violations get logged to syslog via kernel logging, 
(debug deny) 

(allow sysctl-read) 

; Mount / umount commands 

(deny f ile-write-mount f ile-write-umount) 

; System is read only 
(allow file-read*) 
(deny file-write*) 

; NOTE: Later rules override earlier rules. 

; Private areas 

(deny file-write* 

(regex " ~/private/var /mobile/ Applications/ .*$")) 
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(deny file-read* 

(regex " Vprivate/var /mobile/Applicat ions/ . *$") ) 

SQLite uses /private/var/tmp 

TBR: <rdar ://problem/5805879> SQLite doesn't honor 
the TMPDIR environment variable 
(allow file-write* 

(regex " "/private/var/tmp (/ I $) ") ) 
(allow file-read* 

(regex " " /private/var/tmp (/ I $) ") ) 

; TBR: <rdar : //problem/5806524> 
(allow process-exec 

(regex " Vprivate/var/tmp$") ) 

; TBR: <rdar : //problem/5830139> 
(allow file-write* 

(regex " Vprivate/var/tmp/UpdatedSnapshots/$") ) 

; Permit reading and writing in the App container 
(allow file-read* 

(regex " Vprivate/var/mobile/Applications/ \ 

XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX(/ I $) ") ) 

(allow file-write* 

(regex " Vprivate/var /mobile/Applications/ \ 
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/ (tmp I Library I Documents) (/ I $) " ) ) 

(allow process-exec 

(regex #" Vprivate/var/mobile/Applications/ \ 
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/ . *\ . app(/ I $) ") ) 

; Allow Address book access via filesystem 

; This is an SQLite3 database - there is room to make the rules tighter 
(allow file-write* 

(regex " Vprivate/var /mobile/Library/ AddressBook(/ I $) " ) ) 
(allow file-read* 

(regex " ~/private/var /mobile/Library/ AddressBook(/ I $) " ) ) 

; Allow keyboard db access via filesystem 

; This is a custom file format. There is room to make the rules tighter 
(allow file-write* 

(regex " Vprivate/var /mobile/Library (/Keyboard) ?(/!$)")) 
(allow file-read* 

(regex " Vprivate/var /mobile/Library (/Keyboard) ?(/!$)")) 

; Pictures, but not other media 

; Allow photo access via filesystem. There is room to make the rules tightejr 
(deny file-write* 

(regex " Vprivate/var /mobile/Media (/ I $) ") ) 
(deny file-read* 

(regex " Vprivate/var /mobile/Media/" ) ) 

(allow file-write* 
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(regex " Vprivate/var/mobile/Media/com. apple . itunes . lock_sync$") ) 
(allow file-read* 

(regex " Vprivate/var/mobile/Media/com. apple . itunes . lock_sync$") ) 

(allow file-write* 

(regex " ~/private/var/mobile/Media/DCIM(/ I $) ") ) 
(allow file-read* 

(regex " ~/private/var/mobile/Media/DCIM(/ I $) ") ) 

(allow file-read* 

(regex " Vprivate/var /mobile/Media/Photos (/ I $) " ) ) 

; Mach lookups. There is room to make the rule tighter, 

(allow mach-lookup) 

; ; (global-name "PurpleSystemEventPort") 

;; (global-name "com. apple . CARenderServer") 

;; (global-name "com. apple . eventpump") 

;; (global-name "com. apple . springboard. migserver") 

;; (global-name "com. apple . system. notif ication_center") ) 

(deny process-fork) 

; For ASL logs - /var/run/asl_input (XXX: socket can now be named) 
; (allow network-outbound) 

; (to unix-socket "/private/var/run/asl_input ") ) 

(allow network*) 

; To allow crash reporter / exceptions to kill the process 
(allow signal (target self)) 
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